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(57) Abstract: In an electronic transaction system, a buyer (B) initiates a purchase from a seller (S), which sends an offer to sell 
(OS) to the buyer (B) over the Internet The buyer (B) sends payment details (PD) over the Internet to a buyer authenticator (BA), 
which authenticates the identity of the buyer (B) and sends a buyer authentication message (BAM), over a secure network to a seller 
authenticator. From the contents of the buyer authentication message (BAM), the seller authenticator (S A) identifies the seller (S) and 
sends the offer to sell message (OS) to the seller (S). The seller (S) checks whether the offer to sell message matches that originally 
sent to the buyer, and if so sends an offer to sell confirmation (OSC) to the seller authenticator (S A), where the message is forwarded 
to the buyer authenticator (BA) and thence to the Buyer (B). Fulfilment (F) of the order is initiated and the seller sends a transaction 
confirmation to the seller authenticator (SA). The system uses the authenticators as intermediaries to establish a virtual trust domain 
between buyer and seller. Security is increased by requiring that both buyer and seller confirm the existence of the transaction to 
other parties. A modification is also disclosed in which the buyer authenticator calculates any tax due on the delivery of the order, 
and obtains the buyer's agreement to pay this tax before the transaction can proceed. 



SECURE TRANSACTION SYSTEM 

Technical Field 

The present ' invention relates to a secure transaction system, 
particularly for use over a public network, and particularly but not exclusively 
for processing payment transactions. 

Background Art 

There has been considerable activity in the field of Internet-based 
electronic commerce to develop appropriate standards for secure electronic 
transactions Ce-commerce'). The standards aim to provide: 

privacy of information - such that the content of a transaction cannot 

be read by a third party; 

data integrity - to ensure that the content cannot be changed during 
transmission across the Internet; 

authentication of the parties to the transaction - to avoid fraudulent 
activity by the buyer and/or seller; and 

non-repudiation of the transaction - to provide evidence of the 
transaction should it subsequently be disputed by one of the parties. 

Much activity has been focussed on the development of SET (Secure 
Electronic Transactions), a protocol designed to protect Visa and Mastercard 
transactions, defined in the 'Secure Electronic Transaction (SET) 
Specification', 23 February 1996. However, SET is recognised as being 
difficult to implement and expensive to develop and support. 
Interoperability of components from different suppliers continues to give 
cause for concern. Moreover, the portability and inherently insecure nature 
of software-based solutions are recognised as a limitation to the widespread 
adoption of the protocol. 



Retailers already active in e-commerce find it difficult to understand 
the value of adopting SET. Many are content with SSL (Secure Sockets 
Layer, defined in 'The SSL Protocol Version 3.0', March 1996) and are not 
prepared to change their approach without incentives from financial 
institutions. The latter have meanwhile not developed a business case for 
the adoption of SET. SET therefore seems unlikely to be used extensively, 
at least in the short term. 

The current e-commerce model, as shown in Figure 1, replicates that 
used for card purchases in a physical environment in which a buyer is 
physically present at the seller's premises, or conducts a transaction with the 
seller over the telephone. The buyer B sends a purchase request PR to the 
seller S. for example by selecting a particular item from a web page hosted on 
behalf of the seller S, and receives purchase information PI from the seller, 
confirming the price and identity of the item selected and prompting the buyer 
for payment details. The buyer B submits the payment details PD ? such as 
card and buyer details, to the seller S. 

The seller S then submits an Authorization Request AR to an Acquirer 
A, such as the seller's bank, who passes the Authorization Request AR to the 
Issuer I of the card used by the buyer B in the transaction. The Issuer 
checks that the card and buyer details contained in the Authorization Request 
AR are correct and that the payment is within the buyer's authorized limit. 
If the payment is authorized, the Issuer sends an acceptance message ACC to 
the Acquirer A, who passes the acceptance message ACC to the seller S. 
The seller S then fulfils F the transaction, by delivering the item ordered 
and/or issuing confirmation that the order has been accepted and the payment 
will be debited from the buyer's account. The seller S then sends a 
transaction confirmation message TCF to the Acquirer A. 

In considering security issues, it is important to differentiate between 
traditional fraud perpetrated via the Internet and 'Internet Fraud", new types of 
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fraud specific to the Internet, which cannot be perpetrated over other channels 
or can be undertaken far more easily over the Internet. In an e-commerce 
transaction, the buyer B interacts with the seller S over the Internet, which 
gives rise to security concerns. One concern is that account-related 
5 information passes through a number of intermediary servers between the 
buyer B and the seller S in a way that cannot in general be controlled. 
Retention of the account details by intermediary servers or within the seller's 
server can be used for the purposes of fraud. Another concern is fraudulent 
activity by buyers, in which stolen or invalid account details are given, and 

10 fraudulent activity by sellers, in which payment is obtained without the 
transaction being fulfilled. Until fears of fraudulent sellers can be 
overcome, buyers will not widely accept such a transaction model. 
Likewise, sellers need to be reassured against fraudulent activity by buyers B. 
For example, there is a rising incidence of 'Internet Fraud' in which the 

15 fulfilment stage F itself takes place over the Internet, such as the downloading 
of software from a 'download shop'. 

The document EP-A-0 779 587 discloses a payment settlement system 
for on-line shopping in which the user selects an item from an on-line shop 
over the Internet, but sends credit card data via a separate settlement network 

20 to a 'service centre 1 which sends the payment details to an 'approval centre' 
(e.g. a card issuer) for authorization and notifies the operator of the on-line 
shop if the payment has been authorized. The service centre also sends the 
order data to the operator, so that the order can be fulfilled. While such a 
system avoids the transmission of account details over the Internet, it is 

25 difficult to see what advantage is gained over the well-known method of 
identifying products over the Internet, and subsequently sending credit card 
details directly to the relevant shop by telephone or fax. Moreover, the 
system is still open to fraud, since there is apparently no means of establishing 
trust between the user and the shop, and is vulnerable to replay attacks. 



A further problem associated with Internet shopping is that of import 
taxes, such as duty and value added tax (VAT). An on-line shop may not 
have a warehouse within the same country or economic area as the buyer and 
therefore the ordered goods have to be imported by the buyer, usually by mail 
or courier. The buyer is therefore liable to pay import taxes, which vary 
according to the country as well as the type of goods, so that the buyer does 
not usually know the tax due and cannot readily judge the total cost of the 
purchase. Frequently, the cost advantage of shopping over the Internet is 
cancelled by import taxes, so ideally the buyer would like to know the total 
cost before proceeding with the transaction. Moreover, the goods may be 
impounded or delayed by customs. If the goods are not detected by 
customs, the import taxes are often not paid at all by the buyer. 

Statement of the Invention 

In accordance with one aspect of the present invention, there is 
provided a system for conducting a payment transaction between a paying 
party and a receiving party, in which transaction identification information is 
transmitted from one of the parties to the other. The paying party transmits 
an instruction to pay to an intermediary, and the transaction identification 
information is transmitted from the party which receives it to the 
intermediary, which then transmits the transaction identification information 
to the party which originally transmitted the transaction identification 
information. The payment is not allowed to proceed unless the transaction 
identification information as received from the intermediary matches that 
originally transmitted. In this way, the existence of the current transaction 
is confirmed by both parties before the payment is allowed to proceed, 
preventing 'replay' fraud in which information from a previous transaction is 
replayed by the receiving party, or by a party intercepting the previous 
transaction, to trigger repeat payments. 
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To allow the intermediary to transmit the transaction identification 
information to the originating party, the intermediary is provided with 
information identifying the originating party in the current transaction. 
Therefore, the intermediary is able to check the identity of the originating 
party and only to transmit the transaction identification information to the 
originating party if that party is authorised to use the system. This aspect 
also prevents bogus on-line shops from obtaining account information or 
payment by passing themselves off as trusted shops. If the bogus shop 
identifies itself as a trusted shop and sends this information to the buyer, this 
identification information will be transmitted by the buyer to the intermediary, 
which then contacts the trusted shop. The trusted shop has no record of the 
current transaction and therefore prevents the payment being made. 

According to another aspect of the present invention, there is provided 
a payment transaction system for conducting a payment transaction between a 
1 5 buyer and a seller, in which a buyer authenticator, in communication with the 
buyer, verifies the authenticity of the buyer, a seller authenticator, in 
communication with the seller, verifies the authenticity of the seller, and 
payment instructions for the transaction are transmitted from the buyer 
authenticator to the seller authenticator. This system greatly simplifies the 
20 establishment of a trust relationship between the buyer and the seller, by 
reducing the problem to that of establishing trust between the buyer 
authenticator and the seller authenticator. The authenticators may each 
serve a large number of buyers and sellers, so that the number of possible 
connections between buyer authenticators and seller authenticators over which 
25 trust must be established is greatly reduced. Furthermore, whereas the 
buyer must be allowed to communicate via the Internet in order to encourage 
acceptance of the system, the buyer and seller authenticators can be 
interconnected by a more secure network, such as a circuit-switched network. 
The trust relationship between buyer and buyer authenticator. and between 
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seller and seller authenticate* can be easily established by pre-registration, 
whereas direct pre-registration between buyers and sellers is not feasible. 
Hence, this four-party model breaks the trust problem of the huge number of 
potential connections between buyers and sellers into the much more 
5 manageable number of connections between each buyer authenticator and its 
registered buyers, between each buyer authenticator and each seller 
authenticator, and between each seller authenticator and its registered sellers. 
Thus, the certification hierarchy of SET can be replaced by, for example, 
different secret keys for each connection, the secret keys being set during 
1 0 preregistration or by separate communications between authenticates. 

According to a further aspect of the present invention, there is 
provided a system for conducting a purchase transaction between a buying 
party and a selling party, in which information identifying the goods to be 
purchased is transmitted to an intermediary, which calculates an additional 

15 amount due to a party other than the selling party dependent on the identity of 
the goods to be purchased and preferably the destination to which the goods 
are to be delivered. Preferably, the additional amount is indicated to the 
buying party and the purchase transaction is only allowed to proceed if the 
buying party confirms that the additional amount should be paid. Preferably, 

20 the intermediary automatically triggers the payment of the additional amount 
if the purchase transaction is allowed to proceed. One advantage of this 
aspect is that the additional amount, such as an import tax, is automatically 
paid so that delivery can proceed without delay or tax evasion. Another 
advantage is that the buyer knows the total payment due before entering into 

25 the purchase transaction. 

Brief Description of the Figures 

Specific embodiments of the present invention will now be described 
with reference to the accompanying drawings, in which: 



Figure 1 is a diagram of the stages in a conventional payment 
transaction; 

Figure 2 is a diagram of the stages in a payment transaction system in 
an embodiment of the present invention; 

Figure 3 is a diagram showing the technical means by which the 
transaction of Figure 2 may be conducted; 

Figure 4 is a diagram of the relationships of trust between the parties 
in the system of Figure 2; 

Figure 5 is a diagram showing a virtual trust relationship between 
buyer and seller as a result of the relationships shown in Figure 4; and 

Figure 6 is a diagram showing a protocol for calculating and paying 
import taxes, which can be applied to the protocol shown in Figure 2. 

Modes for Carrying Out the Invention 
Transaction Protocol 

An embodiment of the present invention will now be described with 
reference to Figures 2 and 3, which show a sequence of interactions for 
processing a payment transaction. As in the conventional system, the buyer 
B operates a buyer terminal BT, which may be a general purpose computer or 
dedicated Internet terminal running TCP/IP and Internet browser software, 
and browses a website hosted on a sellers server SS, via the Internet. The 
Internet browser software may include a 'plug-in', or a discrete application 
may be run, which implements the transaction protocol of this embodiment, as 
performed on the buyer's terminal BT. The buyer B indicates a desire to 
purchase one or more items, such as goods or services, by selecting an item 
displayed within the web browser, which sends a Purchase Request message 
PR via the Internet to the seller S. 

* 

In response to the Purchase Request Message PR, the seller S then 
sends to the buyer B, over the Internet I, an Offer to Sell message OS, 
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including details of the intended purchase and the seller's identity, preferably 
in a form which can be verified later by the seller but is difficult to reproduce 
by another party. The Offer to Sell message includes a seller agreement 
reference identifying a previously concluded agreement between the seller S 
and the seller authenticator SA. 

On receipt of the Offer to Sell information OS, the software on the 
buyer's terminal BT enters an authentication process with the buyer B. This 
process may comprise reading a smartcard carrying account details and 
identification information of the holder of the card arid inputting a PIN and/or 
biometric information from the buyer B. This information may be digitally 
signed, for example by generating and encrypting a hash of the information, 
using a key stored on the smart card and not known to the buyer. The buyer 
B may also digitally sign the Offer to Sell information. The signed 
information and Offer to Sell information are sent as payment details PD over 
the Internet I to a buyer authenticator BA, which may be a server BAS 
operated by the buyer's bank. 

The buyer authenticator BA checks the details of the buyer B 
contained within the payment details PD ? for example by validating the 
signature of the Offer to sell information using a key previously assigned to 
the buyer B when issuing the smartcard, and checking that the PIN and/or 
biometric information are correct. As an alternative, the PIN and/or 
biometric information may be validated at the buyer's terminal BT against a 
PIN or biometric information stored on the smart card. If the PIN and/or 
biometric information do not match after a predetermined number of attempts, 
the software on the buyer's terminal BT may terminate the transaction and 
optionally send a message to the buyer authenticator BA indicating a failed 
attempt to use the smartcard. 

In either case, if the buyer is authenticated, but not otherwise, the 
buyer authenticator BA sends a buyer authentication message BAM via a 



secure channel to a seller authenticator SA, which may be a server SAS 
operated by the seller's bank. The secure channel may be a circuit switched 
connection via a private network PN, or via a public network such as a PSTN 
or ISDN. The buyer authentication message BAM includes the Offer to Sell 
information, payment information, and a flag indicating whether the buyer has 
been authenticated. The seller authenticator SA checks the seller agreement 
reference in the Offer to Sell information and, if this reference corresponds to 
seller agreement recognised by the seller authenticator SA, sets up a 
communications channel to the seller identified by the seller agreement 
reference using pre-stored connection details. For example, where the 
connection to the seller's server SS is via a leased line, the seller authenticator 
routes all messages intended for the seller through that leased line. Where the 
connection is a dial-up connection, the seller authenticator SA dials a number 
pre-stored in the seller agreement record indicated by the seller agreement 
reference. 

The seller authenticator forwards the Offer to Sell Information to the 
seller, for example via a leased line connection LL, or the Internet I. The 
Offer to Sell information is digitally signed by the seller authenticator. This 
signature may be generated by a secret key known only to the seller S to 
which the Offer to Sell information is to be sent, and established during pre- 
registration of the seller with the seller authenticator. 

The seller verifies the seller authenticator's signature and checks 
whether the Offer to Sell Information was indeed originated by itself in a 
current transaction. For example, the seller may include a unique transaction 
number in the Offer to Sell information, generated in a sequence which is 
difficult to predict by another party. The unique transaction number and 
other information unique to the current transaction and included in the Offer 
to Sell information may be encrypted using a secret key stored in the seller's 
server SS. 
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If the seller verifies the seller authenticator's signature and that the 
transaction is current, it sends an Offer to Sell Confirmation message OSC via 
the Internet I back to the seller authenticator SA. The Offer to Sell 
Confirmation message is forwarded to the buyer authenticator via the secure 
channel and thence to the buyer B via the Internet I. At each stage, the 
recipient party verifies the identity of the sender of the Offer to Sell 
Confirmation Message, for example by verifying a digital signature by the 
sending party of the Offer to Sell Confirmation message. The Offer to Sell 
Confirmation Message includes information derived from the Offer to Sell 
Information, which is unique to the current transaction, so that replays of 
Offer to Sell Confirmation Messages can be detected. The seller S then 
performs a fulfilment operation F with the buyer, by initiating the delivery of 
the purchased item or items to the buyer B or by delivering the item over the 
Internet in the case where the item purchased is software, data, or some 
interactive service such as advice or support. The seller also sends a 
transaction confirmation TCF to the seller authenticator SA which triggers 
the clearing and settlement of the payment in the transaction through 
conventional channels, as currently used by issuers such as Mastercard (RTM) 
and Visa (RTM). 

Trusted Domains 

One of the bases of the SET protocol is the creation of a trust 
hierarchy based on public key certificates. This requires the signatory of a 
public key certificate to be trusted by the authenticating party, or for the 
authenticity of the signatory to be established from one or more higher levels 
of public key certificate, the highest level of which is signed by a trusted 
party. The SET trust hierarchy is necessary because the payment transaction 
is conducted between parties having no pre-existing trust relationship. 



11 

In contrast, the protocol of the embodiment described above controls 
security through a chain of trust comprising trust domain dl between the 
buyer B and the buyer authenticator BA, trust domain d2 between the buyer 
authenticator BA and the seller authenticator SA, and domain d3 between the 
seller authenticator SA and the seller S, as represented by Figure 4. An 
appropriate level of security can be applied independently to each link, using a 
security technique suitable for that trusted domain. Examples of such 
techniques have been given above, but other techniques may be substituted 
within the abilities of the skilled person. 

The buyer B has a pre-existing relationship with the buyer 
authenticator BA, for example through a registration procedure. The buyer 
authenticator's server may maintain an electronic wallet or personal electronic 
data store (PEDS) for the buyer, so that the account details of the buyer are 
stored at the buyer authenticator Server BAS and are not transmitted over the 
Internet from the buyer to the buyer authenticator BA. Instead, the buyer 
authenticator BA transmits the account details of the buyer B to the seller 
authenticator only when authorized to do so by the buyer. 

The buyer may be issued with a smart card storing encryption keys 
and/or algorithms by means of which an on-line authentication protocol is 
conducted with the buyer authenticator BA. The buyer authenticator BA is 
required to underwrite the transaction sent to the seller against fraud by the 
buyer, and therefore it is the responsibility of the buyer authenticator to verify 
the identity of the buyer. 

The trusted domain d2 between the buyer authenticator BA and the 
seller authenticator SA operates through an international payment system such 
as that used between banks under the Visa or Mastercard systems, or the 
Global Trust system as announced on 21 October 1998 in New York by ABN 
AMRO, Bank of America, Bankers Trust, Barclays Bank, Chase Manhattan, 
Citibank, Deutsche Bank and Hypo Vereinsbank, and CertCo, now known as 
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; Identrus' ™ and joined by two further members, Canadian Imperial Bank of 
Commerce and Sanwa Bank. This type of trusted domain operates through 
an intermediary which certifies all buyer and seller authenticators using a 
standard certified identity. 

The seller authenticator SA has a pre-existing relationship with the 
seller S, for example by pre-registration. The seller authenticator SA 
guarantees the authenticity of the seller S and accepts at least some liability 
for transactions with that seller. 

Through the use of the overlapping trusted domains dl, d2 and d3, 
there exists a virtual trusted domain D between the buyer B and the seller S, 
as illustrated in Figure 5. 

The above described embodiment achieves several advantages over the 
SET protocol: 

- account information is not passed from the buyer B to the seller S 
across an open network (e.g. the Internet) 

- the amount of account information transmitted from the buyer B to 
the buyer authenticator BA across the open network (e.g. the Internet) may be 
further limited by the use of electronic wallets at the buyer authenticator' s 
server 

- the seller S only gains access to account information of the buyer 
once both the buyer B and the seller S have been authenticated, in the Offer to 
Sell information 

- hashing techniques are used to protect the integrity of the data 

- mutual authentication of the buyer and seller is achieved through the 
use of trusted domains 

- Authentication of the buyer allows subsequent repudiation issues to 
be resolved 

- Security issues are simplified by the use of trusted domains 

- payment guarantee can be provided prior to virtual fulfilment. 
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The above transaction system also allows buyer authenticators BA and 
seller authenticators SA flexibility in their respective relationships with 
buyers B and sellers S. Seller authenticators can provide financial incentives 
to sellers S to encourage them to trade through the system, and buyer 
authenticators can create whatever transaction protocols and business 
processes are necessary to alleviate the buyers' concerns about security. The 
transaction system is based around the position of trust that financial 
institutions, as buyer authenticators and seller authenticators, enjoy with their 
customers as buyers and sellers, and among themselves, by the use of existing 
or planned trust systems. 

Tax Calculation 

An additional protocol which may be added to the protocol shown in 
Figure 2 will now be described with reference to Figure 6. With the Offer to 
Sell message OS, the seller S transmits to the buyer B Classification of Goods 
information CG and Country of Export information CE. The Classification 
of Goods information CG identifies the goods to be sold in the transaction 
according to a standard classification, such as the Harmonized System (HS) 
classification used by customs authorities. If multiple different types of 
goods are being purchased, falling under different classifications, the 
Classification of Goods message lists the value of goods to be purchased 
under each classification. The Country of Export information CE identifies 
the country or tax jurisdiction from which the goods will be exported. The 
buyer B includes the Classification of Goods and Country of Export 
information in the Payment Details message PD. 

The buyer authenticator BA stores, for example on its server BAS, a 
database of import tax rates due on different classifications of goods, as a 
function of the country of export and the country of import. The buyer 
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authenticate* also has available the address to which the goods will be 
delivered; this may be the address of the buyer B as registered against the 
account from which the payment will be made, and may be provided in the 
payment details PD or be pre-stored at the buyer authenticator Server BAS. 
Alternatively, if the goods are ordered as a gift for delivery to another address, 
that address is supplied by the buyer B. From this, the buyer authenticator 
BA derives the country or jurisdiction to which the goods are to be delivered. 
The buyer authenticator BA then calculates the import tax payable by the 
buyer according to the applicable tax rate retrieved from the database, using 
the identifications of the country of import, the country of export, and the 
value and classification of the goods. The import tax information TI is 
transmitted from the buyer authenticator BA to the buyer B. The software 
running on the buyer's terminal BT displays the import tax information and 
asks the buyer B whether to proceed with the transaction. If the buyer 
confirms this, a tax confirmation message TC is sent from the buyer to the 
buyer authenticator. 

Later during the transaction the buyer authenticator BA, in response to 
receipt of the Offer to Sell Confirmation OSC, initiates a payment TP of the 
import tax due from the buyer's account to the account of the customs 
authority responsible for collecting import taxes for the country of delivery of 
the ordered goods. In this way, the payment of import taxes is automated and 
the delivery of goods should not be delayed by customs authorities. 
However, the taxes are only paid with the consent of the buyer, and once the 
transaction has been confirmed by both the buyer B and the seller S. 

As one possible alternative, the buyer B may provide sufficient 
information to the buyer authenticator BA to allow the tax information TI to 
be sent back to the buyer B, before the rest of the Payment Details PD are sent 
to the buyer authenticator. This provides greater comfort to the buyer that the 
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payment for the transaction and for any taxes due cannot be made until the 
buyer B has confirmed that the taxes are acceptable. 

As another alternative, the buyer B only transmits the Classification of 
Goods information CG and the Country of Export information CE to the 
5 buyer authenticator BA once the buyer B has received the Offer to Sell 
Confirmation OSC. The protocol then proceeds, with the Tax Information TI 
being sent to the buyer B and the buyer replying with the Tax Confirmation 
1 TC, in response to which the buyer authenticator B A initiates payment of the 
taxes. This alternative allows the buyer B to proceed with the transaction 
10 without paying the taxes automatically, and may therefore be more attractive 
to the buyer B. 

It will be understood that some types of goods are not subject to 
import taxes in some countries, and some countries do not impose import 
taxes on any imports from certain other countries, such as countries within the 
15 European Union. If no tax is payable, the protocol may proceed without 
requiring a tax confirmation TC from the Buyer B, and optionally without 
sending the tax information TI to the Buyer. 

Although the above protocol has been described with reference to 
taxes, it could alternatively be used in situations where certain taxes are 
20 included in the price charged by the seller, but these taxes can be reclaimed by 
the Buyer. In that case, the Buyer Authenticator may initiate a claim from the 
relevant tax authority for a tax refund to be paid to the buyer's account. 

Alternative Protocols 

25 In the transaction described above, the payment details are submitted 

for payment processing by the seller authenticator, once the transaction 
confirmation is received. However, the payment details may be submitted for 
processing by other parties. For example, the seller S may submit the payment 
details for processing directly, rather than through the seller authenticator SA. 



16 

Furthermore, the payment may be pre-authorised before fulfilment F 
takes place. For example, the buyer authenticator BA may be the issuer of 
the smart card used by the buyer. In that case, the buyer authenticator BA 
confirms that the use of the card is authorised, in the buyer authentication 
message BAM. Payment processing is then triggered by the offer to sell 
confirmation OSC being received by the buyer authenticator BA. 
Alternatively, the transaction confirmation TCF may be forwarded from the 
seller authenticator to the buyer authenticator BA, whereby the payment 
processing is triggered. 

In an alternative form of pre-authorisation 7 the seller authenticator may 
request authorisation for the payment from the card issuer and terminate the 
transaction protocol if authorisation is denied. For example, on receipt of the 
offer to sell message, the seller authenticator may submit the payment details 
to the card issuer, and only forward the offer to sell message to the seller if the 
payment amount is authorized by the issuer. 

• In the above described embodiments, the Offer to Sell message OS is 
generated by the seller S and returned to the seller for confirmation via the 
buyer authenticator BA and the seller authenticator SA. Alternatively, the 
seller S may send the information content of the purchase request PR to the 
seller authenticator SA ? which information is passed to the buyer authenticator 
and then returned to the buyer B, the transaction not being allowed to proceed 
to payment and delivery until the buyer has confirmed that the Purchase 
Request PR is current. However, the buyer must still send the payment 
details PD to the buyer authenticator BA and thence to the seller authenticator 
SA, so that the protocol requires a greater number of separate information 
transfers to take place. 

The functions of the buyer authenticator BA and the seller 
authenticator SA may be combined into a single party, so that the buyer 
Authentication Message BAM is an internal message which is not transmitted 
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over external communications links. This eventuality is possible in the above 
described embodiments, if coincidentally the buyer B and the seller S are 
using the services of the same bank as their respective authenticates. 
Alternatively, the protocol may be designed so that the buyer authenticator 
5 BA and the seller authenticator SA must be the same party. Although this 
three-party arrangement may still benefit from other aspects of the transaction 
protocol, the centralised authenticator would then need to establish trust 
relationships with a very much larger number of users, both as buyers and 
sellers, than would the separate buyer authenticators BA and seller 
10 authenticators SA. Moreover the buyers and sellers could not rely on their 
existing relationships with their banks, but would have to register with the 
centralized authenticator as a new organisation. 

The above protocol is advantageously applied to a payment 
transaction, but could be applied to a transaction in which certain other types 
15 of agreement are concluded between two parties. For example, the buyer 
may instead be entering into a contract to buy a property, such as a house, 
from the seller. The buyer authenticator, on request by the buyer, provides 
details of the financial position of the buyer to the seller authenticator together 
with details of the cost of the property. The seller authenticator checks from 
20 these details as to whether the buyer is likely to be able to pay for the 
property, and sends a simple confirmation or denial message, together with 
identification of the current transaction, to the seller. In this way, the seller 
can check that the buyer's financial status is sufficient without the buyer 
having to supply detailed financial status information directly to the seller, 
25 which would put the seller in an advantageous position in negotiating the 
price. Moreover, fraudulent attempts to obtain financial information about 
the buyer can be prevented, in the same way as access to account information. 
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CLAIMS 

1 . A method of conducting an electronic transaction between a first party 
and a second party, including: 

5 initiating the transaction between the first and second parties, 

in response to initiation of the transaction, generating by the second 
party transaction identification information substantially unique to the 
initiated transaction, 

transmitting the transaction identification information from the second 
1 0 party to the first party, 

transmitting the transaction identification information from the first 
party to an intermediary, 

transmitting the transaction identification information from the 
intermediary to the second party, 
15 comparing, by the second party, the transaction identification 

information received from the intermediary with the transaction identification 
information as generated by the second party in a current transaction, and 

preventing the transaction from proceeding to completion if the 
transaction identification information received from the intermediary does not 
20 match the transaction identification information generated by the second 
party. 

2. A method as claimed in claim 1, wherein the intermediary identifies 
the second party, and selectively transmits the transaction identification 

25 information to the second party, in response to said transaction identification 
information. 

3. A method as claimed in claim 1 or 2, wherein the second party 
determines whether the transaction identification information received from 
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the intermediary matches the transaction identification information generated 
by the second party and transmits to the intermediary a transaction 
confirmation message if said determining step yields a positive result. 

5 4. A method as claimed in any preceding claim, wherein the intermediary 
comprises a first party intermediary arranged to communicate with the first 
party and a second party intermediary arranged to communicate with the 
second party, the first party intermediary being connected to the second party 
intermediary via a communications network. 

10 

5. A method as claimed in any preceding claim, wherein the first party is 
a buying party and the second party is a selling party in an electronic payment 
transaction. 

15 6. A method as claimed in claim 5 when dependent on claim 3, wherein 
the intermediary initiates payment in the transaction in response to said 
transaction confirmation message. 

7. A method as claimed in claim 5 or claim 6. further including initiating 
20 delivery by the second party in fulfilment of the transaction if the transaction 

identification information received from the intermediary matches the 
transaction identification information generated by the second party. 

8. A method of conducting an electronic transaction between a first party 
25 and a second party, including: 

connecting the first party to the second party and initiating the 
transaction via a first communications channel; 
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transmitting transaction information from the first party to the first 
party authenticator and verifying the identity of the first party at the first party 
authenticator via the second communications channel, 

transmitting the transaction information from the first party 
5 authenticator to a second party authenticator via a third communications 
channel, and 

connecting the second party authenticator to the second party via a 
fourth communications channel, whereby the identity of the second party is 
verified by the second party authenticator, 
10 wherein the transaction is prevented from proceeding to completion 

unless the identity of the first party is verified by the first party authenticator 
and the identity of the second party is verified by the second party 
authenticator. 

15 9. A method as claimed in claim 8, wherein the identity of the first party 
is verified by transmitting first party identification information from the first 
party to the first party authenticator and comparing the first party 
identification information with identification information stored by the first 
party authenticator. 

20 

10. A method as claimed in claim 8 or claim 9, wherein the identity of the 
second party is verified by the second party authenticator by comparing at 
least part of said transaction information with second party identification 
information stored by the second party authenticator. 

25 

11. A method as claimed in claim 8 or claim 9, wherein the identity of the 
second party is verified by the second party authenticator by receiving second 
party identification information over the fourth communications channel and 
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comparing said second party identification information with information 
stored at the second party authenticator. 

12. A method as claimed in any one of claims 8 to 1 1, wherein said first 
5 party authenticator stores account information relating to the first party and 

transmits said account information to the second party authenticator if the 
identity of the first party is verified, the account information not being 
transmitted by the first party to the first party authenticator during the current 
transaction. 

10 

13. A method as claimed in any one of claims 8 to 12, wherein said third 
communications channel is set up over a network. 

14. A method as claimed in any one of claims 8 to 13, wherein the first 
1 5 communications channel is carried by a public packet-switched network. 

15. A method as claimed in claim 14, wherein the second communications 
channel is carried by the public packet-switched network: 

20 16. A method as claimed in any one of claims 8 to 15, wherein said 
transaction is an electronic payment transaction, and payment is initiated by 
one of the first part authenticator and the second party authenticator. 

17. A method of conducting a goods ordering transaction between an 
25 ordering party and a supplying party, including: 

transmitting, from the supplying party to the ordering party, supply 
identification information relating to the supply of the goods in the 
transaction, 



WO 01/01361 



PCT/GB99/02017 



22 

transmitting, from the ordering party to an intermediary, said supply 
identification information, and 

calculating, at said intermediary, an amount due to a party other than 
the supplying party on the basis of the supply identification information. 

18. A method as claimed in claim 17, including transmitting amount 
information identifying said amount to said ordering party. 

19. A method as claimed in claim 1 7 or claim 1 8, further including: 
initiating payment of said amount to said party other than said 

supplying party. 

20. A method as claimed in claim 19 when dependent on claim 18, 
wherein said payment is only initiated on confirmation by the ordering party. 

21. A method as claimed in claim 1 9 or claim 20, wherein said payment is 
initiated by said intermediary. 

22. A method as claimed in claim 21 when dependant on claim 20, 
wherein the ordering party transmits a confirmation message to the 
intermediary if said payment is confirmed, and the intermediary initiates 
payment of the amount in response to said confirmation message. 

23. A method as claimed in any one of claims 1 7 to 22, further including 
transmitting a payment authorization message, relating to a payment from the 
ordering party to the supplying party, from the ordering party to the 
intermediary. 
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24. A method as claimed in claim 23 when dependent on claim 22, 
wherein the intermediary prevents said payment from the ordering party to the 
supplying party unless the confirmation message is received from the ordering 
party. 

5 

25. An electronic transaction system arranged to perform the method 
according to any preceding claim. 

26. Electronic communications apparatus arranged to perform the method 
10 steps carried out by the first party in the method as claimed in any one of 

claims 1 to 16. 

27. Electronic communications apparatus arranged to perform the method 
steps carried out by the second party in the method as claimed in any one of 

15 claims 1 to 16. 

28. Electronic communications apparatus arranged to perform the method 
steps carried out by the intermediary in the method as claimed in any one of 
claims 1 to 7 when not dependent on claim 4, or by one of the first party 

20 intermediary and the second party intermediary in the method as claimed in 
claim 4, or as claimed in claim 5 or claim 7 when dependent on claim 4. 

29. Electronic communications apparatus arranged to perform the method 
steps carried out by the first party authenticator in the method as claimed in 

25 any one of claims 8 to 1 6. 

30. Electronic communications apparatus arranged to perform the method 
steps carried out by the second party authenticator in the method as claimed in 
any one of claims 8 to 16. 
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31. Electronic communications apparatus arranged to perform the method 
steps carried out by the ordering party in the method as claimed in any one of 
claims 17 to 24. 

32. Electronic communications apparatus arranged to perform the method 
steps carried out by the supplying party in the method as claimed in any one 
of claims 17 to 24. 



10 



33. Electronic communications apparatus arranged to perform the method 
steps carried out by the intermediary in the method as claimed in any one of 
claims 17 to 24. 
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